Day 6 的 Security Group 只認得 IP 和 port。一個帶著 ' OR 1=1 的 SQL injection 請求，在它眼裡就是「有人從某個 IP 連 443」，完全正常。像這樣的請求，該由哪一層來擋？
網路封包一層包一層：最外面是 IP 位址（誰送給誰），往裡一層是 TCP/UDP 的 port（送給對方哪個服務），最裡面才是應用程式真正的內容（HTTP 請求的網址、header、body）。這三層在網路模型裡分別叫 L3（網路層）、L4（傳輸層）、L7（應用層），數字越大越靠近應用程式。
| 層 | 看得到什麼 | 誰在這一層工作 |
|---|---|---|
| L3/L4 | IP、port、協定、封包量 | Security Group、NACL（Network ACL）、Shield |
| L7 | HTTP 方法、URL、header、body、cookie | WAF |
回到開頭那個例子：Security Group 只拆到 L4，所以它分不出「正常的 443 請求」和「帶著 SQL injection 的 443 請求」——兩者的 IP 和 port 一模一樣。要看懂請求裡寫了什麼，得靠 L7 的工具才行。
WAF（Web Application Firewall）和 Shield 掛的都是「流量入口」，不是 EC2：Route 53 負責把網域名稱解析到正確的入口；CloudFront 是 CDN，把內容快取到全球邊緣節點；ALB（Application Load Balancer）則是掛在 EC2 前面的負載平衡器，收進所有請求後依規則分給後面的 EC2。ALB 工作在 L7、看得懂 HTTP 內容，這也是為什麼 WAF 掛的是 ALB，而不是掛在 EC2 上。
這張圖的重點：WAF 掛在 CloudFront 或 ALB 上，看得懂請求寫了什麼；Shield 保護範圍更大，Route 53、CloudFront、ALB 都算，看的是流量有多大；GuardDuty 完全不在流量路徑上，是事後讀日誌做分析，抓的是已經發生的異常行為。
WAF 的設定單位叫 Web ACL（Web Access Control List），一個 Web ACL 掛在一個入口資源上——CloudFront、ALB、API Gateway 或 AppSync 都可以掛，EC2 本身不能掛，這也解釋了圖上為什麼 WAF 站在入口，而不是機器旁邊。
Web ACL 裡面是一條一條的規則，每條規則有「條件」和「動作」，動作分四種——Allow（放行）、Block（擋掉）、Count（只計數不動作，用來先觀察規則會不會誤殺）、CAPTCHA/Challenge（要求驗證再放行）。規則來源分三種：
| 規則來源 | 說明 | 例子 |
|---|---|---|
| AWS managed rule group | AWS 維護好的規則包，勾了就生效，AWS 會自己更新 | Core rule set（擋常見的注入、XSS）、Known bad inputs、SQL database rule group |
| Rate-based rule | 統計單一來源 IP 在一段時間內的請求數，超過門檻就擋 | 「同一個 IP 在 5 分鐘內超過 2,000 次請求就 Block」 |
| 自訂規則 | 自己寫比對條件：來源國家、URL 路徑、header 內容、body 裡有沒有某個字串 | 「只允許 TW 和 JP 的流量」「URL 含 /admin 的請求只放行公司 IP」 |
把前面這些規則兜起來，掛在 ALB 上的 Web ACL 大概長這樣：
Web ACL: shop-web-acl（掛在 ALB 上）
規則依優先順序比對，第一條符合的動作就定案：
1. Rate-based 同一 IP 5 分鐘內 > 2000 次請求 → Block
2. Managed AWSManagedRulesCommonRuleSet（注入/XSS）→ Block
3. Geo match 來源國家 NOT IN [TW, JP] → Block
4. 自訂 URL 開頭是 /admin 且來源 ≠ 203.0.113.0/24 → Block
預設動作（都沒符合） → Allow
這幾條規則裡，Rate-based rule 最常用：它不看請求內容，只數次數，所以暴力登入、爬蟲、L7 的洪水攻擊都靠它擋。門檻是「每個來源 IP、每個評估視窗（預設 5 分鐘）」各自計算，不是全站總量。
| Shield Standard | Shield Advanced | |
|---|---|---|
| 費用 | 免費，所有帳號自動啟用 | 每月約 3,000 美元，需簽 1 年 |
| 防什麼 | 常見的 L3/L4 攻擊（SYN flood、UDP reflection 這類） | 同左，再加上更大規模、更複雜的攻擊，含 L7 的偵測 |
| 有人幫忙嗎 | 沒有 | 有，Shield Response Team（SRT）24 小時可以介入 |
| 攻擊期間的擴容費 | 自己吸收 | AWS 退還因攻擊而多出來的 EC2/ELB/CloudFront 等費用（DDoS cost protection） |
| 能保護什麼 | 全部 AWS 資源自動涵蓋 | 要指定資源：CloudFront、Route 53、ALB、NLB、Elastic IP、Global Accelerator |
比起硬記每個服務的定義，用症狀對照更好記——遇到什麼現象，對應到該找哪個服務：
| 我看到的症狀 | 該找誰 | 為什麼是它 |
|---|---|---|
| 日誌裡一堆 SQL injection、XSS 的請求 | WAF | 第七層，看得懂 URL、header、body。AWS managed rule group 勾了就生效，不用自己寫規則 |
| 某幾個 IP 每分鐘打幾千次登入 | WAF rate-based rule | 設一個門檻：單一 IP 在 5 分鐘內超過 N 次就擋 |
| 只想服務特定國家 | WAF geo match | 同上，一條規則 |
| 流量暴增十倍、服務快撐不住 | Shield | L3/L4 的事。Standard 每個帳號預設就有；只有需要「專人 24 小時介入」和「攻擊期間擴容費用 AWS 吸收」時才買 Advanced（每月約 3,000 美元、簽一年） |
| 某台 EC2 半夜 CPU 100%、在跟奇怪的 IP 講話 | GuardDuty | 偵測、不阻擋。讀 CloudTrail/VPC Flow Logs/DNS 紀錄，不用裝 agent，Organizations 可以集中到一個帳號看 |
| 30 個帳號的 ALB 都要套同一組 WAF 規則，新帳號也要自動套、管理員不能自己拿掉 | Firewall Manager | 跨帳號統一管 WAF/Shield Advanced/SG 的政策，要搭配 Organizations |
把上面的分層防護圖全部用上，就是 AWS 的 DDoS 實踐：
① Route 53 ＋ CloudFront 在最前面
→ 全球分散，攻擊流量先被邊緣吸收
② WAF rate-based rule
→ 擋掉單一來源的洪水
③ 真正到達後端的流量
→ 靠 Auto Scaling 撐
④ 預算夠再加 Shield Advanced
→ 換人力（SRT）和費用保護
反過來做——拿掉 ALB、讓 EC2 直接掛 Elastic IP 對外——就是把攻擊面拉到最後一層，等於把邊緣防護全部繞過去。
GuardDuty 跟前面三層不一樣：Shield、WAF、SG 做的都是「封包經過時擋不擋」，GuardDuty 完全不同——它不碰流量，而是持續讀三種既有的紀錄，用威脅情報和機器學習找異常：
| 讀什麼 | 能發現什麼 |
|---|---|
| CloudTrail（誰呼叫了哪個 API） | IAM 憑證被盜用、從沒見過的國家登入、有人在關 CloudTrail |
| VPC Flow Logs（誰跟誰連線） | EC2 在跟已知的惡意 IP 或挖礦礦池講話、被當跳板掃描別人 |
| DNS 查詢紀錄 | 機器在查詢已知的惡意網域、C&C 伺服器 |
不用在機器上裝任何 agent，開了就開始看。它產出的是 finding（發現），例如「這台 EC2 正在跟比特幣礦池通訊」，附嚴重程度——但它只告警，不會自己去擋，要自動處理得自己接 EventBridge 觸發 Lambda 去隔離機器。搭配 Organizations 可以指定一個帳號當 delegated administrator，把所有成員帳號的 finding 集中到那裡看。
| 主題 | 說明 |
|---|---|
| WAF 的 Count 模式 | 新規則先用 Count 跑幾天看它會抓到哪些請求，確認不會誤殺正常流量再改成 Block，是上線 WAF 的標準流程 |
| WAF 掛 CloudFront 還是 ALB | 兩個都能掛，掛在 CloudFront 上攻擊流量在邊緣就被擋掉，不會進到 Region 裡消耗 ALB 和後端資源；只有 ALB 沒有 CloudFront 的架構才掛 ALB |
| Shield Advanced 的 health-based detection | 可以連 Route 53 health check，資源健康狀態變差時更快判定為攻擊、更早介入 |
| Firewall Manager 的角色 | 前面幾個都是「一個帳號、一個資源」設定，Firewall Manager 是跨帳號的政策層：規定「這個 OU 底下所有 ALB 都要掛這個 Web ACL」，新帳號自動套、被拿掉自動補回，要搭配 Organizations |
| Network Firewall 跟 WAF 的分工 | Network Firewall 是 VPC 層級的防火牆，能做網域過濾、IPS 特徵比對，守的是整個 VPC 進出的流量（含非 HTTP）；WAF 只看 HTTP/HTTPS，守的是網站入口。兩者不互相取代 |
某公司的公開電商網站運行在 Application Load Balancer 後方的 EC2 instance 上。資安團隊在應用程式日誌中發現大量帶有 SQL injection 與跨站腳本（XSS）特徵的 HTTP 請求，同時有少數幾個來源 IP 在每分鐘發出數千次登入嘗試。公司要求在不修改應用程式程式碼、且維運負擔最低（LEAST operational overhead）的前提下阻擋這些請求。
解決方案架構師應該建議哪一個做法？
某金融科技公司的交易平台使用 Amazon Route 53、Amazon CloudFront 與 Application Load Balancer，後端 EC2 由 Auto Scaling group 管理。主管機關要求公司必須具備：大規模 DDoS 攻擊發生時有 AWS 專責團隊 24 小時協助應變，以及攻擊期間因 Auto Scaling 擴容而暴增的費用不得由公司自行吸收。目前公司只使用 AWS 帳號預設的防護。
解決方案架構師應該怎麼做才能滿足這些要求？
某集團透過 AWS Organizations 管理 30 個成員帳號，每個帳號都有自己的 Application Load Balancer。資安團隊要求所有帳號的 ALB 都必須套用同一組 AWS WAF 規則，未來新建立的帳號與 ALB 也要自動套用，且任何帳號的管理員都不能自行移除這組規則。公司希望用管理工作最少（LEAST amount of administrative effort）的方式達成。
解決方案架構師應該建議哪一個做法？
elasticloadbalancing:CreateLoadBalancer 呼叫必須同時關聯指定的 WAF web ACL某公司在多個 AWS 帳號中運行數百台 EC2 instance。資安團隊希望能持續偵測已被入侵的 instance（例如被植入挖礦程式、與已知惡意 IP 通訊）以及 IAM 身份的異常 API 呼叫行為，並將所有帳號的發現集中到一個資安帳號檢視。公司不希望在 instance 上安裝額外的 agent，也希望維運負擔最低（LEAST operational overhead）。
解決方案架構師應該建議哪一個做法？
某新聞網站運行在 Application Load Balancer 後方的 EC2 Auto Scaling group 上，過去曾在重大新聞期間遭遇流量型 DDoS 攻擊導致服務中斷。公司預算有限，暫不考慮 AWS Shield Advanced，但希望依照 AWS 的 DDoS 防護最佳實踐重新設計架構，讓攻擊流量盡量在到達 EC2 之前就被吸收或阻擋。
解決方案架構師應該採取哪兩項做法？（選擇兩項）
WAF 是第七層防火牆，看得懂 HTTP 請求的內容：AWS managed rule group 有現成的 SQL injection 與 XSS 規則，勾選即生效；rate-based rule 則直接針對「單一 IP 在 5 分鐘內的請求數」設門檻，剛好對應暴力登入。掛在 ALB 上不用改應用程式，也不用自己維護規則。
A 的 NACL 只能擋 IP、看不懂請求內容，自建反向代理更是把維運負擔全攬回來。C 解的是別的問題：Shield Advanced 針對的是第三、四層的 DDoS 流量規模，不是逐一檢查 HTTP 內容。D 技術上 Network Firewall 能做深度封包檢查，但它是 VPC 級的網路防火牆，要改流量路徑、自己寫 Suricata 規則，對「HTTP 應用層攻擊」來說是過度設計，WAF 才是為此而生的服務。
題目的兩項要求（24 小時專責團隊、攻擊期間的擴容費用保護）正是 Shield Advanced 相對於 Standard 多出來的東西：Shield Response Team（SRT）與 DDoS 成本保護，且受保護資源包含 Route 53、CloudFront、ALB。
A 是誤解：Shield Standard 只自動防護常見的第三、四層攻擊，沒有 SRT，也沒有成本保護。C 的 WAF rate-based rule 是有用的補充，但它只處理第七層的請求速率，既沒有專責團隊、也不會退還擴容費用。D 的 GuardDuty 是偵測服務，不擋流量，也和 DDoS 應變人力無關。
AWS Firewall Manager 就是為「跨 Organizations 統一管理 WAF、Shield Advanced、Security Group 規則」設計的：安全政策會自動套用到現有與新加入的帳號和資源，自動修復功能會把沒有關聯 web ACL 的 ALB 補上，成員帳號的管理員就算手動解除關聯，Firewall Manager 也會偵測到不合規並自動補回。
A 的 StackSets 能把 web ACL 部署出去，但「關聯到 ALB」仍靠人工，新 ALB 不會自動套用，管理員也能自行解除關聯。B 是誤解：SCP 只能允許或拒絕 API 呼叫，無法要求「呼叫時必須附帶某個 WAF 關聯」，也不會替你關聯。D 每個帳號各做一次，Config 只是偵測後通知，仍然要人去修。
GuardDuty 分析 CloudTrail、VPC Flow Logs 與 DNS 查詢紀錄，內建威脅情報與機器學習，能偵測挖礦、與惡意 IP 通訊、IAM 身份的異常 API 行為，不需要在 instance 上裝 agent；透過 Organizations 的 delegated administrator 可以一次為所有成員帳號啟用並集中檢視。
A 解的是別的問題：Inspector 掃的是軟體漏洞（CVE），不是正在發生的入侵行為。B 是自建版的 GuardDuty：要自己維護惡意 IP 清單和比對邏輯，維運負擔最高。C 的 Macie 掃的是 S3 裡的敏感資料，與 EC2 入侵和 API 異常無關。
AWS 的 DDoS 防護最佳實踐是「把攻擊擋在越靠近邊緣越好」：CloudFront 與 Route 53 是全球分散的邊緣服務，本身就能吸收大量流量，而且 Shield Standard 對它們的防護最完整（A）；WAF 的 rate-based rule 則把單一來源的洪水在第七層就擋下，不會到達 EC2（B）。
C 反其道而行：拿掉 ALB、讓 EC2 直接暴露，等於把攻擊面拉到最後一層。D 垂直放大單台機器對流量型 DDoS 幾乎沒有幫助，還多花錢。E 是誤解：NAT Gateway 是讓 private subnet 出去的，不會讓外部流量「進來」給 web 服務，把 web 層搬到 private subnet 還得靠 ALB 才對外，與 DDoS 吸收無關。
iThome鐵人賽
看影片追技術